● Removed entirely

• nodes list+watch — The framework detects the cluster domain by calling GET /api/v1/nodes/{name}/proxy/configz (that's nodes/proxy get). The node name is injected via the downward API; no listing of nodes is ever done.
• pods — The operator never creates or manages Pod objects directly. StatefulSets create pods. This was boilerplate from the initial template.
• endpoints — Auto-created by Kubernetes when a Service is created; the operator never touches them.
• batch/jobs rule — Present since the very first commit (copied from the operator-templating repo in Nov 2021). The Druid operator has never created any Jobs. The orphan cleanup silently skips with a 403 if list is denied, so
  there's no harm removing this entirely.
• get for configmaps, secrets, serviceaccounts - It appears to have been done by accident. Tests run fine without them.

● Verb removals

• update on all rules — All resource creation/mutation goes through client.apply_patch() (SSA = HTTP PATCH). No client.update() or api.replace() (HTTP PUT) calls exist anywhere in the codebase.
• watch on serviceaccounts, rolebindings, poddisruptionbudgets, listeners — These are applied via SSA and tracked for orphan cleanup, but none of them appear in .owns() or .watches() in main.rs, so the controller does not need
  to react to changes in these resources.
• list and watch on secrets — Secrets are managed directly in internal_secret.rs via client.get_opt(), client.apply_patch(), and client.delete(). They are not managed through ClusterResources, so the orphan cleanup for secrets
  gets a 403 and silently skips — which is the intended behaviour.
• patch on druiddclusters — The operator only patches the status subresource via client.apply_patch_status(), which is covered by the separate druiddclusters/status rule. No client.apply_patch() is ever called on the
  DruidCluster object itself.

● The reorganisation was a direct consequence of the verb changes. The original file grouped pods, configmaps, secrets, services, endpoints, and serviceaccounts into a single rule because they all shared the same verb set:

verbs: [create, delete, get, list, patch, update, watch]

After the audit, those resources need different subsets of verbs:

• configmaps + services: need watch (owned by controller), need list (orphan cleanup)
• secrets: no list, no watch (not in ClusterResources, not watched)
• serviceaccounts: need list (orphan cleanup), but no watch

A single RBAC rule applies its verb list uniformly to all resources in it, so you can't express "list+watch for configmaps but not for secrets" in one rule. The only way to set different verbs per resource is to split them into
separate rules.